This is very similar to an API suggestion I made on discord, however it sounds like cart would prefer a slightly different direction: https://discord.com/channels/691052431525675048/931614194229477417/931974884534415380

In short, instead of adding a render layer component on rendered entities, the suggestion was that we should do the reverse - register the components we want to render in a pass, with that render pass. This leaves the open question of how to unregister entities from the main pass, because by default we want all 3d things to render into the main pass. The suggested answer was that we wrap PbrBundles in a Mesh3d type, and register Mesh3d with the main pass. This way, if you want to render your mesh in another pass, you would make a PbrBundle and add your MyUiMesh component to it.

In cart's words:

Gotcha. yeah feel free to experiment. I would also like to consider paths that don't need that extra abstraction. Ex: a Hud entity will be a "hud thing" by nature of having Hud components. A normal "3d mesh" entity will be a "main pass" thing by nature of having normal 3d mesh components.

Personally, I'm not convinced cart's suggestion as I understand it is a better route. I prefer something like what you've done here, in which case we might add a MainPass component to PbrBundle or a wrapper type - which is what we had in 0.5, the MainPass component was removed unintentionally.

One suggestion I'd like you to consider, regardless of the outcome of the above, is how plugins might interoperate. How could 3d HUD plugins compose if they all want to draw on top of the main pass? Is this something the user would be responsible for configuring manually? Could a render pass component be passed in as a plugin constructor argument?

The API isn't great, but I'm mostly using the existing API (including RenderLayers, which I like.) I considered something like adding a Z-order to the Camera, but then composing cameras would be difficult, because you really want something more like the render graph, so you can express relations like "after the main pass, but before the UI". So I think it might be best to just rely on the render graph, and improve that API if needed e.g. avoid strings.

The issue of layering has come up when using both egui and Bevy's UI, because it's strange to make bevy_egui depend on bevy_ui just to declare that egui's pass should happen afterwards. Although the app should probably make that decision, anyway.

So this PR is just to make layering possible, and reasonably convenient, but I expect the usability could be improved in later PRs.